[レポート]データベースもマイクロサービス化！Purpose-Built Databaseのススメ #reinvent [DAT209-L]

AWS re:Invent 2019

#レポート

#AWS

#データベース

春田拓海 | Takumi

2019.12.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。DA事業本部の春田です。

本記事は、AWS re:Invent2019の DAT209-L: Leadership session: AWS purpose-built databases のセッションレポートです。

The English version is here.

概要

In this session, Shawn Bice, VP of databases, discusses the AWS purpose-built database strategy and explains why your application should drive the requirements for which database(s) to use, not the other way around. Learn about the purpose of each AWS database service and how AWS customers are using purpose-built databases to build some of the most scalable applications on the planet. If you are a technology or engineering leader and you’re trying to understand how to modernize your data strategy, this session is for you. We discuss using various approaches for new application development, lifting-and-shifting to managed services, and refactoring monolithic database architectures to use purpose-built databases.

このセッションでは、データベースのVP、Shawn Bice氏がAWSの最適なデータベース戦略について議論し、なぜアプリケーション側がどのデータベースを使用するべきかの要件を掘り下げていき、その逆はないのかを説明します。AWSのデータベースサービスそれぞれの目的についてと、AWSのカスタマーはグローバル規模でスケーラブルなアプリケーションを構築するために、どのように最適なデータベースを使っているのかが学べます。あなたがもし、技術やエンジニアリングのリーダーで、今のデータベース戦略をモダンなものにどう変えていくか理解しようとしてるのであれば、このセッションがまさに当てはまります。このセッションでは、新しいアプリケーション開発のための様々なアプローチ方法や、マネージド・サービスへのリフト&シフト、モノリシックなデータベースアーキテクチャのリファクタリングを通して議論していきます。

スピーカー

Shawn Bice
- VP, Databases, Amazon Web Services
Tobias Ternstrom
- Director, RDS & Aurora, Amazon Web Services
Joseph Idziorek
- Principal Product Manager, Amazon Web Services

AWSのデータベースサービスは、ここ数年でかなり多様化してきました。その根本にあるのは、 Purpose-Built Database という用途別に適切なデータベースを使い分けるというAWSが提案するアーキテクチャの戦略です。このセッションでは、それぞれのサービスがどうカテゴリ化されており、どう使っていけば良いのかを、最新のアップデートを含めて、事例と一緒に解説しています。データベースエンジニア必見です！

ここ数年かけて進化してきたアプリケーション・アーキテクチャ

開発者たちの最近の傾向は……
- モノリシックなアプリを構築したくない
- 用途に沿ったシステムを目指している
- 大きなアプリケーションを小さなパーツに分解
- 適切なジョブのために、適切なツールを選択したい

60年代：メインフレーム
80年代：クライアント・サーバー
1. アプリケーションのロジックをデータベースから分離
90年代： 3層構造
1. インターネットが登場
2. クライアント層、アプリケーション層、単一のデータベース層
マイクロサービス
1. クラウド時代に突入し、システムはより特化型に
2. データベースがより特化し始めている

共通のデータベース戦略

データベース戦略を考えるための簡単な方法　→　カテゴリ化

リレーショナル型
1. レスポンスを強固に一貫させたい
2. データ型に一貫性をもたせる
Key-Value型
1. １つのアイテムでも１兆のアイテムでも、同じパフォーマンスが出るようスケール
ドキュメント型
1. システムを止めることなく、JSONのようなデータ型を作成
インメモリ型
1. 頻繁にアクセスするデータは、テーブルのフルスキャンをさせない
グラフ型
1. 高度にコネクションがあるデータ
時系列型
1. 主軸が将来的に続いていくデータモデル
2. アップデートはなし、インサートのみ
台帳型
1. 一度記入したら、二度と変更できない
2. 暗号的な認証性によって、変更不可能なトランザクションログに

顧客が求める最優先事項

マネージドサービスへ移行
1. サービス： RDS, Aurora, ElastiCache, DocDB
2. ツール： SCT, DMS
3. プログラム MAP, Pro Serve, Partner
ライセンスからの開放
1. サービス： Aurora, Amazon Redshift
2. ツール： SCT, DMS
3. プログラム： MAP, DM Freedom, Pro Serve, Partner
モダンなアプリケーション
- 新たな要件
  - ユーザー数： 100万人以上
  - データ量： TB〜PB〜EB
  - パフォーマンス：ミリマイクロ秒
  - リクエスト率：数100万以上
  - アクセス方法：どんなデバイスからでも
  - スケール：アップ、イン、アウト
  - 料金体系：使った分だけ支払う
  - 開発者のアクセス方法：マネージドAPI